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(54) Verfahren zum Planen und Konf igurieren eines Kommunikationsnetzwerkes 

(57) Das Verfahren dient zum Planen und Konfigu- 
rieren eines aus Netzwerkelementen (NE1 , NE2, .... 
NEk) bestehenden Kommunikationsnetzwerkes (N), 
wobeidie Netzwerkelemente (NE1, NE2, .... NEk) uber 
eine Schnittstelle (QS) einstellbar sind. In einer Daten- 
bank (MIB) werden fur verschiedene Betriebszeitpunkte 
geplante Plan-Konfigurationen (PLAN) des Netzwerkes 
(N) gespeichert, mit denen die Betriebsparameter der 
Netzwerkelemente (NE1, NE2, .... NEk) entsprechend 
der Pianung einstellbar sind. Dabei werden fur jede 
Plan-Konfiguration die Netzwerkelemente (NE1, NE2, 
.... NEk) als Objekte mit den einzustellenden Betriebs- 
parametern in einem Objektbaum erfasst und dessen 
Daten im gewunschten Betriebszeitpunkt aus der 
Datenbank (MIB) abgerufen und uber die Schnittstelle 
(QS) dem Kommunikationsnetzwerk (N) zugefuhrt. So 
wird fur diesen Betriebszeitpunkt im Kommunikations- 
netzwerk (N) eine Konfiguration eingestellt, die der 
gewunschten Soli -Konfiguration (SOLL) entspricht. Fur 
kunftige Einsatze geplante Soll-Konfiguration werden 
gebildet, indem der aktuellen Soll-Konfiguration (SOLL) 
eine oder mehrere Plan-Konfigurationen, die die vorge- 
sehenen Konfigurationsanderungen enthalten, uberla- 
gert werden. Zur vorgangigen Uberprufung von 
geplanten Konfigurationen wird das Ergebnis der Uber- 
lagerung sichtbar gemacht. 
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Beschreibung 

Die vorliegende Erfindung betrifft ein Verfahren nach dem Oberbegriff des Patentanspruchs 1 . 

In modernen Kom muni kationsnetzwer ken, wie Fernmeldenetzen, gewinnen Funktionen fur Betrieb und Wartung 

5 (Operation, Administration and Maintenance OAM) immer mehr an Bedeutung. Wie in R Bocker ..Das diensteintegrie- 
rende digitale Nachrichtennetz" Berlin 1990, Seite 158 ft. beschrieben, befasst sich die CCITT-Empf. Q542 fur OAM 
u.a. mit Bedien- und Verwaltungsaufgaben im Zusammenhang mit dem Neueinrichten, Andern oder Erweitern von 
Daten eines Kommunikationsnetzwerkes. Konkret stellt sich den Betreibern solcher Netze immer haufiger die Aufgabe, 
ihr Netz rasch sich andernden Bedurfnissen anzupassen. Solche Anpassungen betreffen z.B. das Bereitstellen zusatz- 

10 licher Leitungen oder das Entfernen von Leitungen in bestimmten Leitungsbundeln bei voraussehbaren Anderungen im 
Verkehrsaufkommen. oder die Anderung der Priorisierung von Leitungen im Netz. Dabei ist fur den Betreiber von 
besonderer Bedeutung, Planungen fur verschiedene Netzkonfigurationen im voraus erstellen und prufen zu kOnnen, 
damit er allfallige sich ungunstig auf den Betrieb des Netzes auswirkende Fehlplanungen rechtzeitig vor der Implemen- 
tierung im Netz feststellen und korrigieren kann. Ferner mussen die verschiedenen Netzplanungen so verwaltet wer- 

15 den, dass sie bei Bedarf rasch abrufbar sind und in das Netz implementiert werden kdnnen. y 

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren anzugeben, das in einfacher Weise 
erlaubt. verschiedene Planungen fur die Konfiguration (Einstellen) elnes Kommunikationsnetzwerkes bereit zu stetlen 
und zu verwalten und das Netzwerk in einem beliebigen Zeitpunkt entsprechend einer bestimmten Planung zu konfigu- 
rieren. 

20 Diese Aufgabe wird durch die im kennzeichnenden Teil des Patentanspruchs 1 angegebenen Massnahmen gelost. 
Vorteilhafte Ausgestaltungen der Erfindung sind in weiteren Anspruchen angegeben. 
Das erfindungsgemasse Verfahren bietet folgende Vorteile: 

Kunftige Konfigurationen eines Netzes k6nnen im voraus mit verschiedenen Planungen ersteltt und auf ihre Eig- 
25 nung fur bestimmte Netzverhattnisse und Verkehrsaufkommen uberpruft werden. 

Die Planungen konnen unabhangig von der Struktur des Netzwerkes erstellt werden. 

Die Erfindung wird nachfolgend anhand einer Zeichnung beispielsweise naher eriautert. Datjai zeigt : 

30 Fig. 1 eine prinzipielle Anordnung zur Durchfuhrung des Verfahrens 

Fig. 2 und 3 konkrete Anwendungen des Verfahrens 

Fig. 1 zeigt eine Anordnung, in der die Erfindung angewendet werden kann. Die Anordnung enthait einen Bedien- 
teil OP, der mit einem Betriebssystem OS verbunden ist, welches mit einer Datenbank MIB (Managed Information 

35 Base) in Verbindung stent und auf diese zugreifen kann. Ober eine Schnittstelle QS ist das Betriebssystem OS mit 

Netzwerkelementen NE1 , NE2 NEk eines Kommunikationsnetzwerkes N verbunden. Netzwerkelemente NE sind 

einstellbare physikalische Teile und Elemente eines Kommunikationsnetzwerkes N etc. Solche Elemente konnen 
sowohl Hardware-Elemente (wie Teilnetze, Knoten/Vermittlungsstellen, Leitungsbundel oder einzelne Leitungen zwi- 
schen den Knoten, Baugruppen, Schnittstellen, Leitungen etc.) als auch Softwareelemente (z.B. geschaltete Verbin- 

40 dungen) sein. Der Bedienteil OP, das Betriebssystem OS. die Datenbank MIB und die Schnittstelle QS bilden 
zusammen ein sogenanntes Telecommunication Management Network TMN, das fur die Steuerung und Einstellung 

der Elemente NE1, NE2, NEk verantwortlich ist. Die Kommunikation zwischen den erwahnten Teilen des TMN 

erfolgt gemass CCITT-Empfehlung X.710 bis X.71 2. Insbesondere ist das Betriebssystem OS fur die Verwaltung, Uber- 
wachung und Konfiguration der Elemente NE zustandig. Unter Konfiguration soli hier das Einstellen bestimmter 

45 Betriebszustande von Elementen NE verstanden werden. Dabei werden die Betriebsparameter der Elemente nach 
Bedarf verandert. Solche Anderungen konnen beispielsweise bei einem vortibergehend erhohten Verkehrsaufkommen 
im Netzwerk N notwendig werden, indem fur diese Zeit mehr Leitungen zwischen bestimmten Knoten im Netzwerk N 
eingeschaltet werden mussen. Ferner konnen Anderungen des Signalisierverfahrens oder die Umleitung des Verkehrs 
von einem Leitungsbundel auf ein anderes zwischen zwei Knoten eines Netzes erforderlich werden. Konfigurationsan- 

50 derungen kdnnen vom Netzbetreiber uber den Bedienteil OP eingegeben werden. Das Betriebssystem OS sorgt dann 
dafur, dass das Netzwerk N entsprechend konfiguriert wird. Als weitere Aufgabe des Betriebssystems OS kann vorge- 
sehen werden, geeignete Massnahmen in einem Element NE einzuleiten. wenn das Betriebssystem OS von diesem 
eine Fehlermeldung erhalt. Die Schnittstelle QS ist eine normierte Schnittstelle (z.B Q3-Adapter gemass CCITT. Rec. 
M.3010), die die zwischen dem Betriebssystem OS und den Elementen NE1 . NE2, NEk ausgetauschten Meldun- 

55 gen und Daten erforderlichenfalls konvertiert. Als Bedienteil OP* kann ein Personalcomputer oder eine Workstation vor- 
gesehen werden, uber die die Befehle fur das Betriebssystem OS eingegeben werden. Eine Bildschirmanzeige 
ermoglicht dem Betreiber interaktiv mit dem Betriebssystem OS zu kommunizieren. 

Fur jedes vorn Management Network TMN verwaltete Element NE des Kommunikationsnetzwerkes N ist in der 
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Datenbank MIB ein Objekt (Managed Object gemass CCITT-Rec. M.3010) vorhanden. Jedes Objekt enthait die Eigen- 
schaften und Zustande des von ihm reprasentierten Elementes. Auch jede Funktion, die das Kommunikationsnetzwerk 
N ausfiihren kann, wird in einem Objekt erfasst. Dabei kann ein Objekt ein oder mehrere Elemente Oder Funktionen 
reprasentieren. Umgekehrt kann ein Element Oder eine Funktion auch durch mehrere Objekte reprasentiert werden. 

5 Alle in der Datenbank MIB enthaltenen Objekte stellen zusammen ein Informationsmodell (z.B. gemass Guidelines 

for the Definition of Managed Objects in Abstract Syntax Notation One ASN.1) des zu steuernden Kommunikations- 
netzwerkes N dar. Jede Erzeugung und jede LOschung eines Elementes des Netzwerkes N wird im Modell nachgef uhrt. 
Mit der Definition des Modells wird festgelegt, was der Betreiber des Kommunikationsnetzwerkes N liber das Betriebs- 
system OS im Netzwerk N steuern kann. Die Kommunikation des Betriebssysterns OS mit dem Bedienteil OR der 

10 Datenbank MIB und der Schnittstelle QS erfolgt mittels def inierter Meldungen (Indications, Notifications, Confirmations 
etc.). Das Betriebssystem OS kann uber definierte Kommandos (z.B. CMISE-Kommandos gemass CCITT Rec. 
X.700ff, insbesondere X.71 1) lesend und schreibend auf die Objekte in der Datenbank MIB zugreifen. 

In der Datenbank MIB sind die Soll-Konfiguration SOLL des Netzwerkes N sowie eine Oder mehrere fur verschie- 
dene Betriebszeitpunkle geplante Plan-Konfigurationen PLAN des Netzwerkes N abgespeichert. Sowohl der Soil- als 

is auch den Plan-Konfigurationen liegt das erwahnte Informationsmodell zugrunde. Die Soll-Konfiguration entspricht dem 
Zustand, dem das Netzwerk N im aktuellen Betriebszeitpunkt gemass den Vorgaben des Betreibers tatsachjich ent- 
sprechen muss. 

Die in der Datenbank MIB gespeicherten Plan-Konfigurationen enthalten vom Betreiber des Netzwerkes N uber 
den Bedienteil OP fur einen bestimmten Betriebszeitpunkt eingegebene Konfigurationsanderungen. Sie konnen vom 

20 Betreiber abgerufen und zur Erzeugung von neuen (kunftigen) Soll-Konfigurationen verwendet werden, welche spater 
in einem gewunschten Zeitpunkt im Netzwerk N implementiert werden konnen. Dabei entsteht - wie weiter unten noch 
beschrieben ist - eine neue Soll-Konfiguration durch Uberlagerung einer. bestehend en (aiteren) Soll-Konfiguration mit 
einer oder mehreren Plan-Konfigurationen. Eine derart erzeugte neue Soll-Konfiguration kann dann vor der Implemen- 
tierung in das Netzwerk N dem Betreiber z.B. uber einen Bildschirm sichtbar gemacht werden. Dies ermoglicht dem 

25 Betreiber, beliebige Planungsversuche durchzufuhren. Ferner kann er Fehlplanungen rechtzeitig vor der Implementie- 
rung feststellen und zu korrigieren. 

Nach der erfolgreichen Implementierung einer Plan-Korrfiguration im Netzwerk N wird diese Plan-Konfiguration in 
die Datenbank MIB uberfuhrt. Dabei wird die in der Datenbank MIB enthaltene Soll-Konfigur^ion entsprechend aktua- 
lisiert, indem die Daten der Plan-Konf iguration in die Soll-Konfiguration geschrieben werdea Damit entspricht die Soll- 

30 Konf iguration in der Datenbank MIB dem tatsachlichen Zustand der Netzwerkelemente im Netzwerk N. 

Es kann auch vorgesehen werden, dass die Soll-Konfiguration in der Datenbank MIB selbsttatig durch Auswertung 
von laufend aus dem Kommunikationsnetzwerk N eintreffenden Anderungs-Meldungen (Notification) vorn Betriebssy- 
stem OS aktualisiert wird. Ferner kann vorgesehen werden, dass der Betreiber uber den Bedienteil OP eine Abgleich- 
prozedur auslost, aufgrund der das Betriebssystem OS alle oder nur einen Teil der relevanten Daten in den 

35 Netzwerkelementen NE1, NE2, ... NEk abfragt und mit den Soll-Daten in der Datenbank MIB vergleicht und die Soll- 
Konfiguration in der Datenbank MIB soweit erforderlich aktualisiert. 

Wie erwahnt, entspricht die in der Datenbank MIB eingetragene Soll-Konfiguration immer dem aktuellen Zustand 
der Elemente NE des zu steuernden Kommunikationsnetzwerkes N. Vom Betreiber uber den Bedienteil OP angeregte 
Anderungen der Objekt- Attribute, d.h. veranderbare Daten wie z.B. die Anzahl Leitungen in einem Leitungsbundel, wer- 

40 den vom Betriebssystem OS uber die Schnittstelle QS an das Kommunikationsnetzwerk N ubertragen, wo dann eine 
entsprechende Konfigurationsanderung vorgenommen wird. Auch hierzu werden CMISE-Kommandos verwendet. 
Dabei kann vorgesehen werden, dass alle Operationen, die der Bediener am Bedienteil OP eingibt. zunachst vom 
Betriebessystem OS im Informationsmodell auf Zuiassigkeit gepruft und vom Betriebssystem OS nur dann an das 
Netzwerk N weitergegeben werden, wenn die Operation gultig ist. 

45 Anhand von Fig. 2 wird nachfolgend ein konkretes Anwendungsbeispiel der Erfindung beschrieben. Dabei wird 
angenommen, zwei Knoten (Vermittlungsstellen) A und B eines Kommunikationsnetzwerkes N seien momentan durch 
drei Verbindungsleitungen miteinander verbunden. Diese aktuelle Konfiguration des Netzwerkes N soil nun geandert 
werden. Dabei wird die Anzahl Verbindungsleitungen zwischen den Knoten A und B von drei auf zwei reduziert, indem 
die Leitung 2 ausgeschaltet wird. 

so In Fig. 2a ist die aktuelle Soll-Konfiguration „Soll" des Netzwerkes N als Ausgangszustand mit zwei Knoten und mit 
drei Verbindungsleitungen in einem Objektbaum dargestellt. Im Baum enthalten die Knoten A und B je drei Leitungen 
1,2 und 3. die mit ihren Endpunkten im jeweils anderen Knoten gekennzeichnet sind, d.h. auf den zugehorigen Lei- 
tungsendpunkt im anderen Knoten referenzieren. Fur den Knoten A sind dies die Leitungsendpunkte NB1, NB2 und 
NB3, fur den Knoten B die Endpunkte NA1 , NA2 und NA3. 

55 In Fig. 2b ist der Objektbaum einer fur einen bestimmten Einsatzzeitpunkt geplanten Konfigurationsanderung 
(Plan-Konfiguration „Plan n") des Netzwerkes N mit nur noch zwei Verbindungsleitungen zwischen den Knoten A und 
B gezeigt. Die Plan-Konfiguration baut auf der gleichen Objektbaum-Struktur auf wie die Soll-Konfiguration in Fig.2a 
auf. Gemass Plan-Konfiguration .Plan n" weist der Baum die unveranderten Objekte Netzwerk N, Knoten A und B 
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sowie die zu Idschenden Objekte NA2 (Endpunkt der Leitung 2 im Knoten A) und NB2 (Endpunkt der Leitung 2 im Kno- 
ten B) auf. Die zu loschenden Objekte NA2 und NB2, welche die zu eliminierende Leitung 2 reprasentieren, sind in Rg. 
2b mit „x n gekennzeichnet. Im gewunschten Zeitpunkt kOnnen die Daten der Plan-Konfiguration .Plan n" mit dem 
CMISE-Kommando „Action Download" uber das Bedienteil OP vom Betriebssystem OS in das Netzwerk N uberfuhrt 

5 (implementiert) werden, worauf dort die Einstellungen der betreffenden Netzwerkelemente NE entsprechend geandert 
werden. Nachher wird in der Datenbank MIB die Soll-Konfiguration von Fig. 2a mit den Daten der Plan-Konfiguration 
von Fig. 2b uberschrieben. Daraus resultiert neue Soll-Konfiguration gemass Fig. 2c, in der gemass Planung die Lei- 
tung 2 zwischen den Knoten A und B als nicht mehr existiert, entspricht dann dem neuen aktuellen Zustand des Netz- 
werkes N. Die verwendete Plan-Konfiguration ..Plan n" kann in der Datenbank MIB aufbewahrt und fur eine spatere 

10 Planung zur Verfugung gehalten werden. Die neue Soll-Konfiguration ..Soil" bleibt im Netzwerk N wirksam. bis sie durch 
Implementierung einer neuen Plan-Konfiguration verSndert wird. 

Fur den Betreiber eines Kommunikationsnetzwerkes kann es nun sehr nutzlich und im Hinblick auf kunftige Anfor- 
derungen an das Netzwerk hilfreich sein, wenn er vorsorglich verschiedene Planungen durchfuhren und testen kann, 
bevor er deren Ergebnis in das Netzwerk implementiert. So kann er insbesondere auch allfailige Fehlplanungen fest- 

15 stellen und rechtzeitig korrigieren, bevor sie sich im Netzwerk ungunstig auswirken. Hierzu wird vorgesehen, aus.der 
Planung resultierende neue geplante Soll-Konfigurationen dem Betreiber des Netzwerkes N sichtbar zu machen ^und 
beispielsweise auf einem Bildschirm darzustellen. Im folgenden wird eine solche neue vorerst nur geplante Soll-Konfi- 
guration im Gegensatz zu einer tatsachlich im Netzwerk N bereits implementierten Soll-Konfiguration ..Soil" als 
'geplante Soll-Konfiguration ..SolLPIan n m bezeichnet. Eine geplante Konfiguration „Soll:Plan n" ist also eine aus einer 

20 bestimmten Planung resultierende, jedoch noch nicht im Netzwerk N implementierte neue Soll-Konfiguration. Eine 
geplante Soll-Konfiguration „Soll:Plan n" wird erzeugt. indem eine Plan-Konfiguration „Plan n" in nachfolgend beschrie- 
bener Weise der aktuellen Soll-Konfiguration „Soir uberlagert wird. 

Die Namensgebung (Naming) der einzelnen Objekte im genannten Informationsmodell erfolgt gemass CCITT-Rec. 
X.720 (insbesondere Kap. 6 ..Principles of containement and naming"). Die zur vollstandigen Identif ikation eines Objek- 

25 tes erforderliche Adresse besteht aus einem Distinguished Name (DN), der aus einer Sequenz von Relative Distinguis- 
hed Names (RDN) aufgebaut ist. So kann der DN fur die Leitung 2 im Knoten A des Netzwerkes N mit der Sequenz 

[ [Netzwerk-ldentifikation:N] [Knoten- Identif ikation: A] [Leitungs-ldentifikation:2] ] 
dargestellt werden. Der Einfachheit halber wird im folgenden eine Schreibweise verwendet. in d^r die in den massge- 
benden CCITT-Rec. vorgesehene Attribut- Identif ikation der einzelnen RDN weggelassen ist. Der DN fur die Leitung 2 

30 lautet dann vereinfacht 
[ [N] [A] [2] ]. 

Der DN fur die Leitung 2 besteht also aus den drei RDN [N], [A] und [2], wobei N der Wert des Attributs ..Netzwerk" (z.B. 
ein Teilnetz innerhalb eines Kommunikationsnetzes), A der Wert des Attributs ..Knoten" (Knoten A im Teilnetz) und 2 der 
Wert des Attributs ..Leitung" (am Knoten A angeschlossene Leitung 2) ist. Selbstverstandlich kann dieser DN mit wei- 

35 teren RDN erganzt werden, wenn dies zur eindeutigen Adressierung bzw. Identifizierung der Leitung 2 in einem 
umfangreichen Kommunikationsnetzwerk erforderlich ist. 

Im Rahmen der vorliegenden Erf indung wird nun im DN eines jeden Objektes ein weiterer RDN eingefuhrt, der zur 
Identif ikation, d.h. zur Unterscheidung der Konfigurationsart (Soll-oder Plan-Konfiguration) dient und dessen Attribut- 
wert zur Erzeugung einer geplanten Soll-Konfiguration speziell verwendet wird. Dabei wird im Naming fur ein Objekt in 

40 der Soll-Konfiguration ein RDN mit dem Attributwert ..Soli", im Naming fur ein Objekt einer Plan : Konfiguration ein RDN 
mit dem Attributwert „Plan n" und im Naming der aus einer Planung hervorgehenden geplanten Soll-Konfiguration ein 
RDN mit dem Attributwert „Soll:Plan n" eingefuhrt. Darin ist „n" eine Nummer zur Unterscheidung von verschiedenen 
fur bestimmte Betriebszeitpunkte des Netzwerkes N vorgesehenen Planungen. Fur die Adressierung der Leitung 2 im 
Knoten A des Netzwerkes N ergibt sich dann in der Soll-Konfiguration der DN 

45 I [Soil] [N] [A] [2] ] 

und in der Plan-Konfiguration der DN 
[[Plann][N][A][2]]. 

Die verschiedenen Attribut-Werte „Soll" und „Plan" im ersten RDN des DN eines Objektes legen somtt fest, ob das 
angesprochene Objekt zu einer Soli- Oder einer Plan-Konfiguration gehCrt. 
so Die spezielle Adressierung wird nun auf die Objekte von Fig. 2 angewendet. Die in Fig. 2a dargestellte Soll-Konfi- 
guration „Soll" enthalt im zugehorigen Objektbaum 9 Objekte mit folgenden Adressen: 
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Netzwerk N 
Knoten A 

Endpunkt Leitung 1 
Endpunkt Leitung 2 
Endpunkt Leitung 3 

B 

1 

/\ 2 
3 



[ [Soli] [N] ] 
[ [Soil] [N] [A] ] 
[[Soil] [N] [A][1]] 
[ [Soil] [N] [A] [2] ] 
[ [Soli] [N] [A] [3] ] 
[ [Soil] [N] [B] ] 
[ [Soil] IN) [B] [1] ] 
[ [Soil] [N] [B] [2] } 
[ [Soil] [N] [B] [3] ] 



Die in Fig. 2b dargestellte Plan-Konfiguration Plan n" enthait im zugehdrigen Objektbaum 5 Objekte, deren 
20 Naming analog wie oben wie folgt gewShlt wird: 



25 



N 



B 



[ [Plan n] [N] ) 

I [Plan n] [N] [A] ] 

[ [Plan n] [N] [A] [2] ] .Remove" 

[ [Plan n] [N] [B] ] 

[ [Plan n] [N] [B] [2] ] .Remote" 
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Die zwei die Endpunkte der Leitung 2 reprasentierenden Objekte, die gemass Planung zu eliminieren ist, enthalten 
zusatzlich ein Attribut ..Intention" mit dem Wert ..Remove", welches die Elimination der Leitung 2 bewirkt. Als weitere 
35 Werte des Attributes .Intention" kSnnen ..Modify", ..Create" und ..Hold" vorgesehen werden, urn entsprechende Planun- 
gen durchfuhren zu kdnnen. 

Eine neue geplante Soll-Konfiguration ..SollPlan n" wie durch Uberlagern der bestehenden Soll-Konfiguration 
..Soil" mit einer Plat-Konfiguration Plan n" erzeugt. Zur Ubertagerung werden samtliche im Informationsmodell enthal- 
tenen Objekte nacheinander angesprochen, wobei zur Abfrage der Befehl (get) verwendet wird. Bei der Adressierung 

40 eines abzufragenden Objektes werden mehrere Werte des Attributs ..Konfiguration" eines RDN - voneinander durch 
einen Doppelpunkt getrennt - angegeben, wie z.B. < get ..Soil Plan n" ) . Dadurch werden verschiedene Objektadressen 
definiert, was bedeutet, dass das Attribut an dieser Stelle einen der angegebenen Werte haben kann. In dem in Fig. 2 
dargestellten Fall wird beispielsweise das Objekt NB2 mit der Abfrage (get [ [SollPlan n] [N] [B] [2]> angesprochen, 
was bedeutet, dass das Objekt mit der Adresse [ [Soli] [N] [B] [2] ] und das Objekt mit der Adresse [ [Plan n] [N] [B] [2] 

45 ] angesprochen werden. Die diese Abfrage durchfiihrende Prozedur der Datenbank MIB sucht nun zunachst in der 
Datenbank MIB nach der in der Abfrage (get [ [SollPlan n] [N] [B] [2] ] ) enthalteneh letzten Objektadresse, in diesem 
Fall der zweiten Objektadresse „[P)an n] [N] [B] [2]", und stellt test, dass in der Plan-Konfiguration .Plan n" ein entspre- 
chend gekennzeichnetes Objekt existiert. Durch den Wert ..Remove" des Attributs ..Intention" kann das Betriebssystem 
OS feststellen, dass dieses Objekt zu eliminieren ist. was beim Auswerten und Anzeigen des Ergebnisses der Uberla- 

50 gerung entsprechend berucksichtigt wird. In der Anzeige wird dieses Objekt dann in einer bestimmten anderen Farbe 
Oder sonstwie als ..eliminiert" gekennzeichnet. 

Bei der Abfrage des Objektes NA1 mit (get [ [SollPlan n] [N] [A] [1] 1 ) wird hingegen keine korrespondierende 
Objektadresse [ [Plan] [N] [A] [1] gefunden. Deshalb sucht die Abfrageprozedur in der Soll-Konfiguration ..Soil" nach der 
zweitletzten in der Abfrage formulierten Objektadresse, in diesem Fall der ersten Objektadresse mit dem Attribut ..Soil". 

55 Sie findet diese in [ [Soil] [N] [A] [1] ] und erkiart diese Adresse demzufolge als gultig. Die Abfrageprozedur sucht also 
aufgrund der Abfrage (wie z.B. (get [ [SollPlan n] [N] [A] [1] ] >) aufeinanderfolgend von ..rechts nach links" in den 
betreffenden Konfigurationen (Plan- bzw. Soll-Konfiguration) nach einer gultigen Objektadresse, d.h. nach einer 
Adresse, zu der in den Konfigurationen tatsachlich auch ein Objekt existiert. Wenn dabei keine gultige Adresse gefun- 
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den wird erfolgt Ober das Betriebssystem OS eine entsprechende Ruckmeldung zum Bedienteil OP gemass CCITT 
X.71 Iff. In gleicher Weise wird mit alien Objekten (NA, NA1 ... . NB, NB1 ... ) des Objektbaums verfahren. 

Somit entsteht durch die Oberlagerung der Soll-Konfiguration .Soil" (Fig.2a) mit der Plan-Konfiguration .Plan n" 



N 





[ [SolkPlan n] [N] ] 


-> 


[ plan n] [N] ] 




[ [SolkPlan n] [N] [A] ] 


-» 


[ plan n] [N] [A] ] 


1 


[ [SolhPlan n][N] [A] [1] ) 


-» 


[ [Soil] [N] [A] [1] ] 


2 


[ [SolkPlan n] [N] [A] [21 ] .Remove" 


•» 


[ plan n] [N] [A] [2] ] .Remove" 


3 


[ [SolkPlan n] [N] [A] [3] ] 


-» 


[ [Soiq [N] [A] [3] ] 



B [ [SolkPlan n] [N] [B] ] ■» I [Plan n] [N] [B] ] 

1 [ [SolkPlan n][Nl[B][1]] -> [ [Soli] [N] [B] [1] ] 

2 [ [SolkPlan n] [M] [B] [2] 1 .Remove" ■» [ [Plan n] [N] [B] [2] ] .Remove" 

3 [ [SolkPlan n] [N] [B] [3] ] -> [ [Soil] [N] [B] [3] ] 

wie sie in Fig 2c auch bildlich dargestellt und in der die Endpunkte der Leitung 2 aufgrund des Intention-Attributs 
..Remove" als eliminiert gekennzeichnet ist. In der Kolonne links ist die Oberlagerung. in der Kolonne rechts das dem 
Betreiber angezeigte Ergebnis der Oberlagerung dargestellt. / 

In dem anhand von Fig. 2 beschriebenen Beispiel wird eine neue geplante Soll-Konfiguration .SolkPlan n" durch 
Oberlagerung der aktuellen Soll-Konfiguration ..Soil" mit einer einzigen Plan-Konfiguration ..Plan n" erzeugt. Es ist aber 
auch denkbar. eine neue Soll-Konfiguration „Soll:Plan n" mit mehreren Plan-Konfigurationen .Plan 1". ..Plan 2". ... " zu 
erzeugen Auf diese Weise lasst sich das Netzwerk N schrittweise vorsorglich fur bestimmte Zeitpunkte planen. mdem 
die Soll-Konfiguration mit einer ersten Platt-Konfiguration uberlagert wird und so jeweils eine neue geplante Soll-Konfi- 
guration entsteht, die ihrerseits in weiteren Schritten nach Bedarf mit einer werteren Plan-Konfiguration uberlagert wird. 
Die Abfrage zur Oberlagerung der Soll-Konfiguration „Soll" mit den drei Plan-Konfigurationen ..Plan 1", .Plan 2" und 

Plan 3" wurde formal (get [ [SolkPlan V.PIan 2:Plan 3] Q [] []] > lauten. Die bei diesen Planungen bzw. Planungs- 

versuchen verwendeten Plan-Konfigurationen kdnnen in der Datenbank MIB gespeichert und bei Bedarf abgerufen 
werden urn im gewiinschten Betriebszeitpunkt das Netzwerk N wie beschrieben zu konfigurieren. Denkbar ist auch. 
nicht nur die verwendeten Plan-Konfigurationen. sondern auch die aus den Planungen resultierenden geplanten Soll- 
Konfigurationen in der Datenbank MIB fur eine spatere Verwendung bereitzuhalten. 

Wie erwahnt, konnen mit dem beschriebenen Vorgehen zum Oberlagern einer Soll-Konfiguration mit einer Oder 
mehreren Plan-Konfiguration auch Fehlplanungen festgestellt werden.Es sei angenommen. bei der Planung gemass 
Fig 2b ist statt des Objektes NB2 faischlicherweise das Objekt NB1 als zu Idschendes Objekt eingetragen worden. Der 
Objektbaum gemass Rg. 3b gibt diesen Sachverhalt wieder. Wenn nun diese fehlerhafte Plan-Konfiguration .Plan n" in 
der beschriebenen Weise auf die Soll-Konfiguration (Fig.3a) ..gelegt" wird. resultiert die fehlerhafte Konfiguration ..Soil" 
gemass Fig 3c. In dieser Konfiguration stellt man fest, dass die Leitung 3 wie gewunscht bestehen bleibt, mdem deren 
Objekte NA3 und NB3 unverandert geblieben sind und richtig referenzieren. Man stellt aber auch fest. dass die Objekte 
NB2 und NA1 auf die Objekte NA2 bzw. NB1 referenzieren. die als nicht mehr vorhanden gekennzeichnet sind. D.h. 
statt wie beabsichtigt nur die Leitung 2 zu eliminieren, wurde durch fehlerhafte Planungsdaten zusatzlich noch die Lei- 
tung 1 eliminiert. Beim Oberlagern der Soll-Konfiguration mit der Platt-Konfiguration wird die Fehlplanung vom Betriebs- 
system OS mit einem Plausibilitatstest unverzuglich erkannt und dem Betreiber am Bildschirm angezeigt. der dann 
rechtzeitig vor der Oberfuhrung der betreffenden Plan-Konfiguration in das Netzwerk N die nOtigen Korrekturen vorneh- 
men kann. Ferner kann das Betriebssystem OS so ausgelegt werden, dar die Implernentierung von Fehlplanungen in 
das Netzwerk N verhindert wird. 

Patentanspruche 

1. Verfahren zum Planen und Konfigurieren eines aus Netzwerkelementen (NE1 . NE2 NEk) bestehenden Kom- 



6 



I: <EP 0854607A1 I > 



EP 0 854 607 A1 



munikationsnetzwerkes (N), dessen Netzwerkelemente (NE1, NE2 NEk) uber eine Schnittstelle (QS) korrfigu- 

rierbar sind, dadurch gekennzeichnef, dass eine Datenbank (MIB) vorgesehen ist, in die fur verschiedene 
Betriebszeitpunkle geplante Konfigurationsanderungen enthaltende Plan-Konfigurationen des Netzwerkes (N) ein- 
gespeichert werden, mitdenen die Betriebsparameter der Netzwerkelemente (NE1, NE2, .... NEk) entsprechend 

5 der Planung einstellbar sind. dass fur jede Plan-Konfiguration die Netzwerkelemente (NE1, NE2 NEk) als 

Objekte mit den einzustellenden Betriebsparametern in einem Objektbaum erfasst werden, dessen Daten im 
gewunschten Betriebe zeitpunkt aus der Datenbank (MIB) abgerufen und uber die Schnittstelle (QS) dem Kommu- 
nikationsnetzwerk (N) zugefuhrt werden, so dass fur diesen Betriebszeitpunkt im Kommunikationsnetzwerk (N) 
eine Soll-Korrf iguration eingestellt wird, die der gewunschten Plan-Konfiguration entspricht. 

10 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass in der Datenbank (MIB) die dem tatsachlichen 
Zustand der Netzwerkelemente (NE) des Netzwerkes (N) entsprechende Soil -Konf iguration (Soli) als Objektbaum 
gespeichert ist, welche Soll-Konfiguration (Soil) jeweils nach der Oberfuhrung einer neuen Plan-Konfiguration 
(Plan n) in das Kommunikationsnetzwerk (N) entsprechend aktualisiert wird. 

75 

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass eine fur einen kunftigen Einsatz geplante Spll-Konfi- 
guration (SolliPlan n) durch Oberlagerung der aktuellen Soll-Konfiguration (Soil) mit einer oder mehreren Plan- 
Konfigurationen (Plan n) gebildet und das Ergebnis der Uberlagerung sichtbar gemacht wird. 

20 4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die Adresse der Objekte der zu uberlagernden Kon- 
figurationen (Soli; Plan n) eine Identifikation enthalt, die darauf hinweist, zu welcher Konfigurationsart (Soil bzw. 
Plan n) das Objekt gehOrt 

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass im Distinguished Name der Objektadressierung ein 
25 Relative Distinguished Name mit einem die Konfigurationsart kennzeichnenden Attributwert eingefuhrt wird. 

6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass die Uberlagerung einer Soll-Konfiguration 
(Soli) mit einer Plan-Konfiguration (Plan n) mit einer Abfrage (get ,.Soll:Plan n"> erfolgt und dabei ubereinstim- 
mende Objektadressen gesucht wenden, wobei die Suche jeweils in der letzten Objektadresse beginnt und bei feh- 

30 lender Obereinstimmung auf die vorhergehenden Objektadressen ausgedehnt wird, bis eine Ubereinstimmung 
gefunden wird. 

7. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass jede durch eine Uberla- 
gerung entstandene geplante Soll-Konfiguration (Soli Plan n) vorder Oberfuhrung in das Kommunikationsnetzwerk 

35 (N) einem Plausibilitatstest unterzogen wird. 

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass wenn der Plausibilitatstest einen Fehler ergibt. die 
Oberfuhrung der betreffenden Plan-Konfiguration in das Netzwerk (N) verhindert wird und die betroffenen Objekte 
angezeigt werden 

40 

9. Anordnung zur Durchfuhrung des Verfahrens nach Anspruch 1 . dadurch gekennzeichnet, dass eine Datenbank 
(MIB) vorgesehen ist, in der die Daten verschiedener Konfigurationen (SOLL; PLAN) des Netzwerkes (N) gespei- 
chert sind, dass ein Betriebssystem (OS) zum Ein-und Auslesen der in der Datenbank (MIB) gespeicherten Daten, 
zum Oberlagern einer Soll-Konfiguration mit einer oder mehreren Plan-Konfigurationen sowie zum Oberfuhren der 

45 Daten in das Netzwerk (N) vorgesehen ist, und dass ein Bediente (OP) vorgesehen ist, uber das dem Betriebssy- 
stem (OS) Befehle und Daten zufuhrbar sind. 



50 
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FIG. 2 
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